Relational database management systems may utilize an active transaction log file (also referred to as a “transaction journal” or “journal file”) or similar facility to record updates done by a transaction to provide transaction integrity and recoverability. This information is also used when the database system fails for some reason and the system needs to be restarted and restored to a “stable state.” Typically this stable state means the most recent point where all completed (committed) updates have been written to the database and any in-flight updates (uncommitted) are removed from the database. Conventional database logs use a fixed-block architecture to store the transaction logs that represent the updates made by the transactions. The fixed-block architecture allows the current log buffer to be rewritten to the same log block multiple times (as needed) to ensure that transaction updates that have been committed are recorded on the physical log file direct access storage device before the actual transaction is allowed to commit or complete. In a typical environment a log buffer may be re-written to the log file direct access storage device multiple times. Such writes to the direct access storage device may be triggered, for example, when certain events take place (such as “commits” saving changes in the database), at certain time intervals, when the log buffer is full, or based on other predetermined or dynamic determined conditions. While the log buffer is being written to the log file direct access storage device, other tasks that need to record transaction information in the log buffer or log file may be held until the direct access storage device write is completed, which may introduce delays in transaction processing.